Hypervivid Tiger Team - Port-Scanning: A Practical Approach
-----------------------------------------------------------

Version 1.0

Author(s):
Doug Hoyte - Senior Programmer



* Introduction
* Your arsenal
* Fundamentals
* Port scanning
* Practical Scanning



Introduction
------------

Often times it is useful, even necessary, to gather as much information as possible
about a remote target. This includes learning all of their network "points of entry",
the operating systems used, firewalling methods employed, services running, etc.

Note that while it certainly is possible to portscan with a windows machine, I will
be focusing on using a unix machine with certain utilities installed. This is due to
Windows' lack of raw socket access (pre Win2K) and the lack of decent, free, portscanners
availble for the platform. In the next section I will share some useful pointers on portscanning. 
Note that root level access is required on your unix machine for many scans.



Your arsenal
------------

Which unix you use is entirely up to you. I suggest you verify that nmap will run on your
flavour of unix before deciding on one in particular. Linux, BSD, and SunOS are good choices.
HP-UX, AIX, IRIX, SCO, XENIX, and the rest of the plethora of unix clones MAY work, but
you'll be sailing untested waters.

Here's the list of other programs you might want to install:
* nmap      (The defacto security scanner)
* nc        (NetCat - The "IP Swiss Army Knife")
* tcpdump   (The original sniffer. Personally, I prefer snort, but tcpdump will run
             on just about any unix out there...)
* lynx      (Excellent console based webbrowser. Always handy to have)


For the Tiger Team member involved in physical audits, nothing is more valuable than
a laptop with a network card in it, running unix. It can be carried around throughout
the company building, and plugged into ethernet jacks and start sniffing/scanning immediatley.
I personally would suggest NetBSD or OpenBSD for this purpose, because they are small,
fast, mobile, and VERY capable unix systems.







Fundamentals
------------


In order to understand how to make your scans efficient and effective, you have to grasp a few
concepts about TCP/IP networking, and how the operating system accomplishes this.

All of the internet (which relies very heavily on TCP/IP) uses packets to send data back and
forth. There is no direct stream of data like, say, a telephone connection. Instead, the
computer sends packets, which are processed, filtered, fragmented, and routed throughout
other computers, until this packet of data reaches its ultimate destination.

If this concept is completely foreign to you, you will probably have much difficulty
understanding basic portscanning. In any case, you must understand how computers
can cary on simultaneous connections to different computers at once. The explanation
can actually get quite detailed, but is the basis of portscanning. Here are the basics:

Every internet connected computer has an IP address (either permanently designated to
that very machine, or dynamically assigned upon connecting to the network) which
uniquely identifies that machine to all other machines on the network. Think of the
IP address as a name for the computer. All packets you want to send to a particular
computer, you would slap that address onto the packets you want to send, and throw that
packet out onto the internet, and let the internet take care of getting that packet
to the machine with the destination's IP address.

But what if I want to have 2 connections to one IP address simultaneously? How will my
computer know which packets are for which connection? Ports, my friend. Each internet
connected computer has 65535 potential ports available to them. Keep in mind that usually
only ports greater than 1024 are designated for general use, with the rest of the ports
reserved for services on machines, like webservers (port 80), FTP servers (port 21), SSH
servers (port 22). At least that's how it's supposed to work. There are to many exceptions
to list. For instance, IRC servers (port 6667), MySQL (port 3306). Note: One of the reasons
why I insisted you have root access on your unix machine is that if you want to listen on a
port belown 1024 in unix, you simply must have root privileges. Unix won't let you "bind" to
that port otherwise. Note that this is not necessary for most portscanning techniques, but
can be very valuable in certain situations.

Okay. So what happens when I, as a client, want to open a connection to a computer
on the internet on a specific port?

This also is quite involved, so I'll summarize.

You slap together a small packet which has a special "flag" set on it: SYN (Synchronizing).
Then you slap on your own IP address (the "source IP"). Then you pick a random, unused port
between 1024 and 65535, and slap that on the packet (the "source port"). Next you slap on
the destination's IP address (the "destination IP"), and the port you want to connect to
("the destination port"). Then you send the packet onto the internet and (hopefully) a few
milliseconds later it will arrive at its destination.

From here on in, all TCP/IP packets for this connection will use the same ports and
IP addresses, except, of course, when the server sends a packet, then the source becomes
the destination, and vice versa.

So, upon recieving the packet, the server must make a decision. First off, does the server
want to talk to this IP address that's knocking on its door, so to speak. If it does,
it will check if the source port is indeed open for communication (SYNchronization, as it
were). If so, it replies with another packet, except this one has not only the SYN
flag set, but also the ACK. If, on the other hand, this port is NOT open, it sends
an ICMP message (which is NOT, in fact TCP/IP, but operates over the internet nonetheless):
an RST (reset). The user at the client's computer would probably get an error message like
"the service you requested is not online at <insert IP address here>".

Assuming that all went well and a SYN/ACK was transmitted, the client will then reply with a packet
with only the ACK flag set. Then, the 2 can begin sending data packets between them (which
all, as a matter of fact, have the ACK flag set). Now this may seem like an awful amount
of trouble to go through to establish a connection... Why not just start sending packets?
Well, if you think about it, this is the minimal amount of communication required for verifying
to both parties that data can, in fact, be sent in 2 directions. Interestingly, there is
a second method of sending data over the internet as well, called UDP/IP, which basically
DOES just start sending packets. Unfortunatley, UDP/IP is renowned for its unreliability.
Not only are packets NOT guaranteed to arrive in order and without data corruption, but
their arrival isn't guaranteed at all! UDP does have its place, though, especially
when you don't need full data integrity (Streaming audio is the classic exmple). nmap offers
UDP/IP scanning techniques too, by the way.)


A couple notes before we proceed to actual port scanning:
* Here's what an IP address might look like: 192.168.24.53.
* All information in this manual deals with IPv4.
* Often, IPs and DNS names can be used interchangably. Think about DNS names, like
  hypervivid.com, as being turned into an IP by the operating system before being
  used by the networking code.
* TCP/IP connections are also closed via ICMP (ideally), or by timeout (as is often the case)
* If a client that DIDN'T request a connection ever recieves a SYN/ACK packet, it is
  supposed to reply with an ICMP message responding appropriately.




Port-Scanning
-------------


Basically, for this section, you can simply throw out all other port scanners, and learn
how to use nmap. nmap is an extremely powerful, free security scanner that, in my opinion,
beats the pants off even the most pricey commercial scanners on the market. A skilled nmap
wielder can scan through firewalls, determine remote operating systems, preform literally
dozens of different types of scans, and even bounce scans off of FTP servers, so the
victim will think the FTP server is scanning them. Congratulations go to Fyodor, the author
of nmap, and all the other hackers who helped make nmap the incredible beast that it is
today.

This is by no means a complete nmap manual. The most complete documentation is, of course,
the freely available source code. Next to that, you have to rely on the man page, even though
the man page neglects to mention several interesting features of nmap that you could only
ever find buried deep inside the source. I'll touch upon several of the different scan
types, OS detection, tips, and a few of these "undocumented features".
Okay, here's a very simple nmap scan:

nmap 192.168.9.3

This uses many defaults. It defaults to a standard TCP scan. You could also have done it like so:

nmap -sT 192.168.9.3


Description of -sT:

Basically, this scan attempts a full TCP/IP connection as described above with every port
listed in nmap's custom /etc/services file. It then reports all ports it finds open.

Note: If you're not, in fact, scanning over the network (for example, nmap localhost), this
is the scan you want to use. It's VERY fast, and most IP loggers don't log TCP/IP connection
attempts from 'localhost'.

Note: If you don't have root on the box you're scanning from, this is the only "standard"
scan you can do as this scan doesn't use raw sockets, and instead relies on the ubiquitous
connect() system call.


Advantages:

*  Fairly fast scan
*  DOESN'T require root privileges.


Disadvantages:

*  VERY easily detectable.




Description of -sS:

So let's consider a "SYN scan", or "half-open scanning" as it is commonly called. Basically
it works like this: Your machine injects a SYN packet of the appropriate port and IP 
address onto the network stream so that your OS doesn't even know it's sending out this packet,
that way it won't be expecting a SYN/ACK packet back from the server. Then, nmap starts
listening directly into the network stream until it sees either SYN/ACKs or the ICMP
messages saying the port is closed. That's all nmap has to do. The OS, upon recieving this
SYN/ACK packet from the scan victim, thinks "I didn't request this connection, I'd better
send an ICMP error message...". It's important that your OS does this, otherwise the server
will sit there expecting an ACK packet for quite some time, which eats up memory and such.
This is referred to as SYN flooding, which is something you DON'T want to do if stealthiness
is your game. (I'll touch briefly on how nmap can be used as a very powerful SYN flooding
tool a bit later). It's called half-open scanning because a full connection is never made.
nmap takes just enough information it needs, and never has to open a full connection.

Advantages:

*  Fairly stealthy...
*  Most firewalling software doesn't log these particular scans, although many do.
*  Reasonably fast scan. Sometimes faster than -sT, sometimes not.


Disadvatages:
*  You need to be root to preform this scan. 
*  I've found this scan can be signifigantly slower than -sT on older hardware with 
   ISA ethernet cards for whatever reason.
*  Still sends packets to the victim that have your IP on them.





Description of -sF, -sX, -sN:

There are 3 other types of "standard" TCP/IP scans: -sF, -sX, and -sN. Basically they have
to do with setting various TCP/IP flags on the packets that you scan with, relying on
the standard methods of handling these unusual packets set out in the networking standards:
the RFCs. To be honest, I get very little use out of any of these scans. They aren't much
more difficult to detect and log than -sS, and you can't be certain that all scanned OSs
respond according to the RFCs, so chances are you'll have to use a different scan just to
confirm the results of these ones! Of course, there are people that really like these
scans. See the nmap man page for details.


Advantages:

*  Debatably more stealthy than SYN scans.
*  These scans will impress your friends if you do them right. :)


Disadvantages:

*  Sometimes you get cryptic, misleading results.
*  Still sends packets to the victim that have your IP on them.





Description of -sI:

This is an exciting new scan that has just recently been incorporated into nmap. Few people
seem to know how it works, but Fyodor has promised us some documentation on this scan soon.
If it works as advertised, this scan has an incredible amount of potential. I've played with
it a bit, but haven't got it working.


Advantages:

*  No packets sent to the victim from your IP!
*  Your friends will idol you if you do them right. :)


Disadvantages:

*  Probably has some serious limitations. This document will be updated when I understand
   more of this scan.




Description of -sA:

This little doozy of a scan is highly underrated, in my opinion. It has a very large amount
of legitimate network debugging uses. Basically it works like this: You want to find out
if a firewall is filtering certain ports (filtering means not letting you see which ports
are open behind the firewall by not returning ICMP messages saying you can't be reached).
Good for mapping out firewall rulesets. Plus if you know a port is open behind a firewall,
you can deduce wether or not you're dealing with a stateful packet filter. You can't find
out which ports are open on internal hosts, but you can determine which hosts to scan
when you get that short, 2 minute opportunity on the internal network after slipping through
a window right before closing time. ;) Seriously, though, in the hands of somebody who
understands firewalling principles, this scan can be incredibly valuable.

Note: When you're reading the nmap manpage, you'll see that it mentions the ACK packets
have random sequence numbers and such. It seems everybodies favorite IDS (intrustion
detection system), snort, was using a clever monitoring trick to see if somebody was
mapping out the firewall ruleset. See, earlier versions of nmap had a fixed value, so
it was trivial to pick them up, and find any GUARANTEED suspicious activity. That's some
nice detective work by the people who make snort. Congrats go to Fyodor too, who fixed it,
enabling us scanners to ACK scan free from worry. :)



Advantages:

*  This stuff is probably never logged.
*  Very useful for the skilled scanner.


Disadvantages:

*  It isn't really a port scan.




Description of -sW:

This is an even cooler scan than -sA. Not only does it use ACK packets instead of SYN packets
to find your targets filtering rules, but it will also report open ports on the target!
It does this via some sort of TCP/IP window size anomalies. Unfortunatley, it only
works for some OSs... (It works for many popular ones, though, including VMS, SunOS 4.X, and BSD)


Advantages:

*  Everything holds from -sA


Disadvantages:

*  Doesn't work on all Operating Systems




Description of -sU:

This is a UDP scan. UDP, or Uniform Datagram Protocol, is a straightforward protocol. You
send a packet, if it gets there, good. Any applications bound to that UDP port on
the destination gets the data. If it's closed, they send back an ICMP message. That's basically
it. -sU just sends UDP packets to all ports in the services file.

UDP isn't that commonly used, but often times it's a good idea to do a quick UDP scan
on a host just to see whats up. For instance they might be running NFS or something.
%90 of the time, I'm simply not interested in UDP ports, so this feature doesn't get a lot of
use.


Advantages:

*  Quite fast, I've noticed.
*  It's good to have a UDP scanning feature.


Disadvantages:

*  Not as useful as the other scans, usually.



Description of -sR:

Once there was a bug in a Beta version of nmap that killed -sR support temporarily... It
went unnoticed for quite some time before Fyodor himself caught the bug. He was somewhat
upset, because nobody had tested -sR on the Beta... I'm sorry Fyodor, but I've never once
used -sR. Has to do with scanning for SunRPC ports, and finding their versions and whatnot.
(See the manpage for info). Personally, I think this scan belongs in an application level
scanner, NOT in nmap, but this is, of course, a matter for continuous debate.




Description of -sO:

This is an interesting scan. It doesn't scan for ports at all. It scans for open
internet protocols that the target is accepting... I've only ever used this out of
curiosity or to impress clients. :)




Description of -sL and -sP:

This would be a good time to bring up an excellent feature of nmap. It can scan more than
one host from a single command line entry! Yes, that's right, you could scan your whole subnet
with this command:

nmap -sS 192.168.0.0/24

or

nmap -sS 192.168.0.0-255

You can do all sorts of crazy combinations, like:

nmap -sS 1,3,9-11.3-9.-1.5-

That would scan a LOT of hosts... I REALLY like how Fyodor did this... It's so... useful!


Anyways, the -sL scan is handy when you have an extremely complicated IP range to scan, and
you just want to make sure nmap is interpreting your command the way you want it. At least,
that's the only use *I* can think of for it... See, -sL DOESN'T scan anything... It doesn't
send any packets out on your network...

-sP is completely different. It pings hosts to see if they're up or not. This is a very
useful scan. Say I wanted to see which hosts are up on my subnet, I'd do a:

nmap -sP 192.168.0.-254

nmap, by default uses both ICMP and ACK packets to identify wether a host is up or not, although
you can change this behaviour with the -P switch, which will be discussed shortly.






-P<insert mode here>

nmap usually wants to confirm that a host is up before scanning it, so it sends out "pings"
to the target and waits for its replies. Often, you'll want different methods of pinging
hosts, or you don't want to ping at all. This is where the -P switch comes in:

See the man page for the different available modes. One of the most useful is -P0. This is
for when you KNOW the host is up, but they are dropping pings.



-F

By default, nmap will scan all ports < 1024, plus the ports listed in nmap's special services
file: /usr/local/share/nmap/nmap-services normally. The -F scan will only scan the ports listed
in the services file. Actually, the "fast" scan isn't signifigantly faster than a normal
scan. You save scanning 435 ports; maybe a few seconds. I almost never use this switch. If
you really want a fast scan, think about which ports you are interested in, and use the -p
switch (keep reading) to narrow down the scan. IF, however, you want to scan all 65535 ports
on a host, you should use this scan:

nmap -p 1- target.com


Which leads us to our next switch...



-p <port range>

This is one of the most commonly used switches. It specifies what ports you actually
want to scan. It uses similar syntax as specifying multiple host scanning, and is
equally flexible.

Some examples:

nmap -p 2-500 target.com
nmap -p 2,4,8,29,500-9000 target.com
nmap -p -300,60000- target.com
nmap -sS -P0 -p 2-500 target.com



-O

Remote operating system identification is one of nmap's coolest features. The hacker community
that develops nmap always sends in new OS "fingerprints" of new or obscure operating systems,
so nmap has an incredible ability to remotley identify almost any internet connected computer.

Note: You must be root to use this feature.
Note: Usually, nmap must know about 1 open and 1 closed port, although there are exceptions.



-I

This option is designed to find out who "owns" the process that is listening on the open
ports you've found. Many default unix installations actually come with an ident daemon
running (port 113), so this option can be quite useful. Keep in mind, though, it is trivial
to write an ident daemon that responds with any user for any process. Never fully rely on this scan.



-g <port>

This switch is an interesting one, and is rarely given the credit it deserves. If the target
only responds to packets from a certain source port, this switch can help get your scan through,
or if a firewall is doing something crazy, like only letting in port 53 as the source port.
This is common on many poorly configured firewalls hiding a DNS server, I'm told. (Ideally,
it would look at the IP too, not just the source port). As with any cool option, this switch
requires root privileges.



-S <IP> and -e <interface>

These 2 switches are most commonly used when nmap, for whatever reason, can't detect which
IP or interface to use for the port scan. nmap will tell you when you need to use these.
The nmap man page raises an interesting point about using the -S switch (probably in parallel
with the -e switch) to fake the scan as coming from a certain IP. You won't, of course, be
able to see the results of this scan. Also, keep in mind, most properly configured routers
at your ISP won't let these packets through if they come from a suspicious IP. See the man
page for details.



-f

Basically, what this switch does is split the IP header over several different fragments
so that many firewalls will let pass these otherwise filterable packets. See the man page
for details.




-D <decoy>[,decoy2,decoy3,ME,decoy4...]

This feature will let you fake scans from different IP addresses, so that the target won't
know for sure who is scanning them. Make sure you include ME somewhere in the -D switch argument
so that you recieve the results. Note that many ISPs won't send out packets with fishy
source addresses on them. Also note that your decoys should be hosts that are up and running
during the scan, or you may SYN flood your target. Conversly, if your goal IS to SYN flood
the target, this would be an ideal way to do it. Consider this:

nmap -sS -P0 -p 1- -D 1.2.3.4,2.3.4.5,3.4.5.6,4.5.6.7 victim.com

Given none of the aforementioned IPs are actual hosts, the server's responses to the SYN
packets (their SYN/ACK packets) will go unanswered. This will eat up connection queue space
on the target for as long as their timeout value is, resulting in a SYN flood.




-T <Paranoid|Sneaky|Polite|Normal|Aggressive|Insane>

This switch controls the speed that you want to portscan. Sometimes, spreading your port
scan packets out will get by an IDS on the target system. Other times, you may just want
to conserve (or saturate) network bandwidth. See the man page for details.



-v and -d

Verbose and debugging. It's often a good idea to use the -v switch, as you will often be able
to determine more information about anything that went wrong. You can use as many -v switches
as you like in the command, and each one cumulatively makes the output more and more verbose.
This stops being effective after about 3 -v switches. -d is the debugging mode, and probably
isn't necessary for everyday scans, but it helps untold amounts in the debugging process.



-iR

Picks random IP addresses to scan. nmap recently endured a massive overhaul to ensure that
these random scans don't scan private (non-routable) networks, or government computers who
probably won't take to kindly to your portscan. This switch is of limited usefulness, but
may by valuable for statistical analysis or seeing how a outward-destined packet filtering
firewall will filter a random array of IPs.



-M <sockets>

This useful option allows you to specify how many sockets you would like to limit nmap to use
for scanning. See, nmap will scan multiple ports at once, and for a normal -sT scan, it must
go through the BSD sockets interface to use the network. Needless to say, any other type of scan
(except possibly -sU) is unaffected by this switch, as it doesn't use the sockets interface at
all: It just directly injects packets onto the network, bypassing the operating system altogether.
This is why root is required. This switch is especially useful on BSD machines, I've noticed.
Some of them (especially on older hardware) seem to jam up and lag a bit while preforming
-sT scans, although I've never seen one crash before. Listen to the man page, though: Use
-sS over -sT whenever possible.



-o<logging method>

Generally, nmap will output its results in human readable form to stdout. Usually, when I want
to save my logs, I'll do this:

nmap -sS target.com | tee /home/doug/scans/target.com-sS

This works just fine for me, but people seem to like using this switch to save output
elsewhere. See the man page for details. One useful feature that I haven't experimented
much with is the --resume switch that will let you resume a canceled nmap scan. Again,
refer to the man page.




Practical Scanning 
------------------

Many novice scanners don't recognize the importance of cataloging your scans. If you simply
port scan to standard output, and read the results, you will often forget your results
and be forced to repreform the scan, which is not stealthy in the least. Create a directory
for storing your scans, and name them appropriatley, with all the switches in the filename,
so as to avoid any confusion.

Always carefully consider what information you are actually after BEFORE you start scanning.
Nothing will give you away faster than a bunch of blind, thoughtless scans. This is what
most IDSs are designed to detect, afterall. For instance, if you want to find the operating
system of a webserver NOT running SSL, use this scan:

nmap -sS -P0 -O -p 80,443 www.target.com

The logic behind this scan is left as an exercise to the reader.

Always keep in mind that anything you do can, and often is, logged.

The only real way to become an expert portscanner is practise, practise, and more practise.
You'll see a lot of strange things if you scan enough computers, and often it is interesting
and educational to discover the causes of these anomalies. Scan your own machines,
scan your friends machines, and you will learn a lot about scanning and networking in
general.
